Data transmission method and mobile terminal

ABSTRACT

A data transmission method and a mobile terminal include taking bytes of data in universal asynchronous receiver/transmitter (UART) format generated by a mobile terminal, simulating UART ports via GPIO ports of a processor of the mobile terminal, and transmitting the bytes of data in UART format divided in batches to a receiving terminal via the GPIO ports. In transmitting the bytes of data in UART format in divided batches to the receiving terminal via the GPIO ports, the processor of the mobile terminal is in a locked state. The processor is in an unlocked state between two adjacent batches of the data transmitting.

CROSS REFERENCE TO RELATED APPLICATION

This is a continuation application of U.S. patent application Ser. No. 15/253,444, filed on Aug. 31, 2016, which is a continuation of and claims priority to International Application No. PCT/CN2015/090625, filed on Sep. 24, 2015. The entire disclosures of the aforementioned applications are incorporated herein by reference.

BACKGROUND Field

The present disclosure relates to mobile terminal field, and more particularly to a data transmission method and a mobile terminal.

Background

In some situations, processors of mobile terminals (such as mobile phones) need to output interface data in multiple types of formats, for example, Inter-Integrated Circuit (I2C), universal asynchronous receiver/transmitter (UART), serial peripheral interface (SPI), and so on. However, in a situation that number of dedicated interfaces of a processor is not sufficient, it is required to utilize general purpose input/output (GPIO) ports to simulate other types of interfaces. Meanwhile, the processor is necessary to control when data and clocks are transmitted or received by time delays. For I2Cs and SPIs which are synchronous data, accuracy of the time delays is not required. Data transmission and reception can be accurately completed via clock triggers as long as the clocks can keep up with the data. However, for UARTs which is an asynchronous communication, the data is collected via the time delays after a receiving terminal detects a starting bit. When the time delays are not accurate, the data is easily wrongly received. Accordingly, the accuracy of the time delays is quite important for the GPIO ports which simulate UART serial ports.

A processor of the mobile terminal can process multiple types of tasks. However, in order to ensure the accuracy of the time delays, it is required to lock the processor to be protected from all interrupting responses. This ensures that the processor does not process other tasks due to other interrupts when a time delay function is operated. As such, another problem is caused. If data, which is transmitted by the simulated UART serial ports takes too long, it is necessary to lock the processor for a long time. Finally, the processor crashes because it is too late to process various interrupts.

BRIEF DESCRIPTION OF THE DRAWINGS

To describe the technical solutions of the embodiments of the present disclosure more clearly, the following briefly introduces the accompanying drawings required for describing the embodiments. Apparently, the accompanying drawings in the following description show only some embodiments of the present disclosure, and those skilled in the art may still derive other drawings from these accompanying drawings without creative efforts.

FIG. 1 is a schematic flowchart of a data transmission method in accordance with an embodiment of the present disclosure.

FIG. 2 is an example of the data transmission method in accordance with an embodiment of the present disclosure.

FIG. 3 is an illustrative block diagram of a mobile terminal in accordance with an embodiment of the present disclosure.

FIG. 4 is an illustrative block diagram of a mobile terminal in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

A clear and complete description of technical solutions provided in the embodiments of the present disclosure will be given below, in conjunction with the accompanying drawings in the embodiments of the present disclosure. Apparently, the embodiments described below are merely a part, but not all, of the embodiments of the present disclosure. All of other embodiments, obtained by those skilled in the art based on the embodiments of the present disclosure without any inventive efforts, fall into the protection scope of the present disclosure.

FIG. 1 is a schematic flowchart of a data transmission method in accordance with an embodiment of the present disclosure. The method in FIG. 1 can begin at block 110.

At block 110, data is generated in UART format in taking bytes by a mobile terminal.

At block 120, UART ports are stimulated via GPIO ports of a processor by the mobile terminal to transmit the bytes of data in UART format divided into batches to a receiving terminal. In transmitting each batch of the data, the processor of the mobile terminal is in a locked state to not respond to any interrupts. The processor is in an unlocked state during an interval between two adjacent batches of the data transmitting.

In the embodiment of the present disclosure, the GPIO ports of the processor of the mobile terminal simulate the UART ports to transmit the data in UART format in divided batches to the receiving terminal. During the data transmission, the processor is set to be in the locked state to not respond to other interrupts to ensure stability of the data transmission. Between two batches of the data transmitting, the processor is set to be in the unlocked state to process other tasks or interrupts, thereby avoiding crashes caused when an AP is in the locked state for a long time.

In at least one embodiment, at block 120, a predetermined number of data bytes is acquired by the mobile terminal. The UART ports are simulated via the GPIO ports of the processor to transmit the predetermined number of data bytes to the receiving terminal. The processor is controlled to be in the locked state. The interval is maintained between every two adjacent batches of data bytes transmitting process until all the predetermined number of data bytes in UART format has been transmitted to the receiving terminal. The processor is in the unlocked state during the interval.

In the related art, some adapters are smart adapters which have MCUs. However, the power adapters do not comprise radio frequency modules. Once the power adapters have bugs or are required to be updated, the power adapters can only be returned to factories. As such, it is time consuming and effort consuming.

In at least one embodiment, the receiving terminal is a power adapter. The mobile terminal is in electrical connection with the power adapter via a charging interface. At block 110, software update information of the power adapter is downloaded by the mobile terminal, and the software update information is converted into the data in UART format by the mobile terminal. At block 120, the UART ports are simulated via the GPIO ports of the processor by the mobile terminal to transmit the data in UART format to UART ports of the MCU of the power adapter in batches.

In the embodiment of the present disclosure, the update information of the power adapter is downloaded via the mobile terminal, and then the update information in the data in UART format is transmitted to the UART ports of the processor of the power adapter (other dedicated ports of the MCU of the power adapter are generally occupied, and the UART ports are not utilized sufficiently yet), thereby implementing the update of the power adapter.

In at least one embodiment, the simulating the UART ports via the GPIO ports of the processor by the mobile terminal to transmit the data in UART format to the UART ports of the MCU of the power adapter in batches may include transmitting the data in UART format to the MCU of the power adapter by the mobile terminal in a process where the power adapter charges the mobile terminal in a common charging mode. The method in FIG. 1 may further include switching the mobile terminal from the common charging mode to a quick charging mode after the power adapter updates the software of the power adapter according to the data in UART format, where a charging rate of the quick charging mode is greater than a charging rate of the common charging mode.

In the embodiment of the present disclosure, the download and the update of the power adapter are achieved on the premise of ensuring that the mobile terminal is charged.

In at least one embodiment, the processor of the mobile terminal is an application processor of the mobile terminal.

The mobile terminal may include the application processor and an MCU (or a baseband processor). The application processor can implement functions of a smart mobile terminal, for example, installation and process of an APP. The MCU can process basic functions related to communication, for example, a call, a short message, and so on.

In at least one embodiment, the method in FIG. 1 may further include simulating the UART ports via the GPIO ports by the mobile terminal to receive data in UART format in divided batches from the receiving terminal. In receiving each batch of the data, the processor of the mobile terminal is in the locked state to not respond to any interrupts. The processor is in the unlocked state during an interval between two adjacent batches of the data receiving.

The data reception is a reverse process of the data transmission. The details can refer to the process of the data transmission and are not described herein.

The data transmission method in accordance with an embodiment of the present disclosure will be described in detail in combination with the following specific example.

FIG. 2 illustrates an example of the processor of the mobile terminal being an application processor (AP). It can be seen from FIG. 2 that the AP transmits 1 byte of data every time. In the process of transmitting the 1 byte of data, the AP is in a locked state to not respond to any interrupts. In the period of time after the transmission of the one byte of data is completed and before the transmission of a next byte of data starts, the AP is in an unlocked state and can process other tasks, thereby avoiding crashes caused when the AP is in the locked state for a long time and cannot respond to other terminals.

The data transmission method in accordance with the embodiment of the present disclosure is described in detail above in combination with FIG. 1 to FIG. 2. Mobile terminals in accordance with embodiments of the present disclosure are described in detail in the following in combination with FIG. 3 to FIG. 4. It should be understood that the mobile terminals in FIG. 3 to FIG. 4 can implement each of the steps in FIG. 1 to FIG. 2 which are not repeated herein to avoid repetition.

FIG. 3 is an illustrative block diagram of a mobile terminal in accordance with an embodiment of the present disclosure. The mobile terminal 300 in FIG. 3 includes a generating unit 310 and a transmitting unit 320. The generating unit 310 is configured to generate data in UART format in taking bytes. The transmitting unit 320 is configured to simulate UART ports via GPIO ports of a processor to transmit the bytes of data in UART format divided into batches to a receiving terminal 350. In transmitting each batch of the data, the processor of the mobile terminal 300 is in a locked state to not respond to any interrupts. The processor is in an unlocked state during an interval between two adjacent batches of the data transmitting.

In the embodiment of the present disclosure, the GPIO ports of the processor of the mobile terminal 300 simulate the UART ports to transmit the data in UART format in divided batches to the receiving terminal 350. During the data transmission, the processor is set to be in the locked state to not respond to other interrupts to ensure the stability of the data transmission. Between two bathes of the data transmitting, the processor is set to be in the unlocked state to process other tasks or interrupts, thereby avoiding crashes caused when the AP is in the locked state for a long time.

In at least one embodiment, the transmitting unit 320 may be specifically configured to acquire a predetermined number of data bytes, simulate the UART ports via the GPIO ports of the processor to transmit the predetermined number of the data bytes to the receiving terminal 350, and maintain the interval between every two adjacent batches of data bytes transmitting process until all the predetermined number of data bytes in UART format has been transmitted to the receiving terminal 350. The processor is in the unlocked state during the interval.

In at least one embodiment, the receiving terminal 350 is a power adapter. The mobile terminal 300 is in electrical connection with the power adapter via a charging interface. The generating unit 310 may be specifically configured to download software update information of the power adapter by the mobile terminal 300 and convert the software update information into the data in UART format. The transmitting unit 320 may be specifically configured to simulate the UART ports via the GPIO ports of the processor by the mobile terminal 300 to transmit the data in UART format to UART ports of an MCU of the power adapter in divided batches.

In at least one embodiment, the transmitting unit 320 may be specifically configured to transmit the data in UART format to the MCU of the power adapter in divided batches in a process where the power adapter charges the mobile terminal 300 in a common charging mode. The mobile terminal 300 further includes a switching unit 330 which is configured to switch from the common charging mode to a quick charging mode after the power adapter updates the software of the power adapter according to the data in UART format. A charging rate of the quick charging mode is greater than a charging rate of the common charging mode. The mobile terminal 300 further includes a receiving unit 340 which is configured to receive data divided in UART format into batches from the receiving terminal 350 via the GPIO ports after the transmitting unit 320 is configured to cause the processor to simulate the UART ports via the GPIO ports of the processor.

In at least one embodiment, the processor of the mobile terminal 300 is an application processor of the mobile terminal 300.

FIG. 4 is an illustrative block diagram of a mobile terminal in accordance with an embodiment of the present disclosure. The mobile terminal 400 in FIG. 4 includes a memory 410 and a processor 420. The memory 410 is configured to store programs. The processor 420 is configured to perform the programs. When the programs are performed, the processor 420 is specifically configured to generate data in UART format in taking bytes and simulate UART ports via GPIO ports of the processor 420 to transmit the bytes of data in UART format divided into batches to a receiving terminal 450. In transmitting each batch of the data, the processor 420 of the mobile terminal 400 is in a locked state to not respond to any interrupts. The processor 420 is in an unlocked state during an interval between two adjacent batches of the data transmitting.

In the embodiment of the present disclosure, the GPIO ports of the processor 420 of the mobile terminal 400 simulate the UART ports to transmit the data in UART format in divided batches to the receiving terminal 450. During the data transmission, the processor 420 is set to be in the locked state to not respond to other interrupts to ensure the stability of the data transmission. Between two batches of the data transmitting, the processor 420 is set to be in the unlocked state to process other tasks or interrupts, thereby avoiding crashes caused when the AP is in the locked state for a long time.

In at least one embodiment, the processor 420 may be specifically configured to acquire a predetermined number of data bytes, simulate the UART ports via the GPIO ports of the processor 420 to transmit the predetermined number of data bytes to the receiving terminal 450, and maintain the interval between every two adjacent batches of data bytes transmitting process until all the predetermined number of data bytes in UART format has been transmitted to the receiving terminal 450. The processor 420 is in the unlocked state during the interval.

In at least one embodiment, the receiving terminal 450 is a power adapter. The mobile terminal 400 is in electrical connection with the power adapter via a charging interface. The processor 420 may be specifically configured to download software update information of the power adapter by the mobile terminal 400 and convert the software update information into the data in UART format. The mobile terminal 400 simulates the UART ports via the GPIO ports of the processor 420 to transmit the data in UART format to UART ports of an MCU of the power adapter in divided batches.

In at least one embodiment, the processor 420 may be specifically configured to transmit the data in UART format to the MCU of the power adapter in batches in a process where the power adapter charges the mobile terminal 400 in a common charging mode. The mobile terminal 400 is further configured to switch from the common charging mode to a quick charging mode after the power adapter updates the software of the power adapter according to the data in UART format. A charging rate of the quick charging mode is greater than a charging rate of the common charging mode.

In at least one embodiment, the processor 420 of the mobile terminal 400 is an application processor of the mobile terminal. The mobile terminal 400 further includes a receiving unit 430 which is configured to receive data in UART format divided into batches from the receiving terminal 450 via the GPIO ports after the processor 420 simulates the UART ports via the GPIO ports of the processor 420.

Those skilled in the art may realize that the units and algorithmic steps of the examples described in conjunction with the embodiments disclosed in the present disclosure may be realized by electronic hardware or the combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software method depends on the specific applications and design constraint conditions of the technical solution. For each specific application, the described functions may be realized by professionals using different methods, but this realization shall not be considered as going beyond the scope of the present disclosure.

It should be appreciated by those skilled in the art that for the purpose of convenience and clarity, the specific operational processes of the above-mentioned systems, devices, and units can refer to the corresponding processes in the above-mentioned embodiments of the methods and are not repeated herein.

It should be appreciated that the disclosed systems, devices, and methods in the embodiments provided by the application can be implemented by other methods. For example, the above-mentioned described embodiments of the devices are merely illustrative. For example, the division of the units is only a logic function division, and other division methods may be adopted in practice. For example, a plurality of units or components may be combined or integrated in another system, or some features may be omitted or are not executed. In addition, the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, and the indirect coupling or communication connection may be in electrical, mechanical or other forms.

The units illustrated as separate components may be or may not be physically separated, and the components displayed as units may be or may not be physical units, that is to say, the components may be positioned at one place or may also be distributed on a plurality of network units. The objectives of the solutions of the embodiments may be fulfilled by selecting part of or all of the units according to actual needs.

In addition, in various embodiments of the present disclosure, the functional units may be integrated in one processing unit, or the function units may separately and physically exist, or two or more units may be integrated in one unit.

When the integrated unit is realized in the form of software functional units and sold or used as independent products, the integrated unit may be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present disclosure substantially, or the part of the present disclosure making contribution to the prior art, or all or a part of the technical solution may be embodied in the form of a software product, and the computer software product is stored in a storage medium, which includes a plurality of instructions enabling computer equipment (which may be a personal computer, a server, or network equipment and the like) to execute all of or part of the steps in the methods of the embodiments of the present disclosure. The aforementioned storage medium includes various media capable of storing program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a disk or an optical disk.

The above description is merely the specific embodiments of the present invention, but the protection scope of the present invention is not limited thereto, any skilled who is familiar with this art could readily conceive variations or substitutions within the disclosed technical scope disclosed by the present invention, and these variations or substitutions shall be encompassed in the protection scope of the present invention. Thus, the protection scope of the present invention shall be subjected to the protection scope of the claims. 

What is claimed is:
 1. A data transmission method applicable to a device to be charged, comprising: generating data in universal asynchronous receiver/transmitter (UART) format; and transmitting the data in UART format in batches to a charging device via general purpose input/output (GPIO) ports of a processor of the device to be charged.
 2. The method of claim 1, wherein, when transmitting the data in UART format in batches to the charging device via the GPIO ports, the processor is in a locked state, and during an interval between two adjacent batches of the data transmitting, the processor is in an unlocked state.
 3. The method of claim 1, wherein the transmitting the data in UART format in batches to the charging device via the GPIO ports, comprises: acquiring data with a predetermined size from the data in UART format which has not been transmitted; simulating the UART ports via the GPIO ports; transmitting the data with the predetermined size to the charging device via the GPIO ports; maintaining an interval; and returning the acquiring data with the predetermined size until all the data in UART format has been transmitted to the charging device.
 4. The method of claim 1, wherein, the generating the data in UART format, comprises: downloading software update information of the charging device; and converting the software update information into the data in UART format.
 5. The method of claim 1, wherein the transmitting the data in UART format in batches to the charging device via the GPIO ports, comprises: transmitting the data in UART format to UART ports of a microcontroller (MCU) of the charging device in batches.
 6. The method of claim 1, wherein the transmitting the data in UART format in batches to the charging device via the GPIO ports, comprises: transmitting the data in UART format in batches to the charging device via the GPIO ports, when the device to be charged is under a first charging mode.
 7. The method of claim 6, further comprising: after the transmitting the data in UART format in batches to the charging device via the GPIO ports, switching the device to be charged to be under a second charging mode, wherein a charging speech of the second charging mode is greater than that of the first charging mode.
 8. The method of claim 1, wherein the processor is an application processor of the device to be charged.
 9. The method of claim 1, further comprising: receiving data in UART format from the charging device via the GPIO ports after simulating the UART ports via the GPIO ports of the processor, wherein in receiving the data in UART format from the charging device via the GPIO ports of the processor, the processor is in a locked state, the processor is in an unlocked state during an interval between two adjacent batches of the data receiving.
 10. The method of claim 1, wherein the processor processes at least one interrupt during an interval between two adjacent batches of the data transmitting.
 11. A device to be charged, comprising: a memory, configured to store a plurality of programs; and a processor, configured to execute the plurality of programs to carry out: generating data in universal asynchronous receiver/transmitter (UART) format; and transmitting the data in UART format in batches to a charging device via general purpose input/output (GPIO) ports of the processor.
 12. The device of claim 11, wherein when transmitting the data in UART format in batches to the charging device via the GPIO ports, the processor is in a locked state, and during an interval between two adjacent batches of the data transmitting, the processor is in an unlocked state.
 13. The device of claim 11, wherein the transmitting the data in UART format in batches to the charging device via the GPIO ports, comprises: acquiring data with a predetermined size from the data in UART format which has not been transmitted; simulating the UART ports via the GPIO ports; transmitting the data with the predetermined size to the charging device via the GPIO ports; maintaining an interval; and returning the acquiring data with the predetermined size until all the data in UART format has been transmitted to the charging device.
 14. The device of claim 11, wherein, the generating the data in UART format, comprises: downloading software update information of the charging device; and converting the software update information into the data in UART format.
 15. The device of claim 11, wherein the transmitting the data in UART format in batches to the charging device via the GPIO ports, comprises: transmitting the data in UART format to UART ports of a microcontroller (MCU) of the charging device in batches.
 16. The device of claim 11, wherein the transmitting the data in UART format in batches to the charging device via the GPIO ports, comprises: transmitting the data in UART format in batches to the charging device via the GPIO ports, when the device to be charged is under a first charging mode.
 17. The device of claim 16, wherein the processor is further configured to execute the plurality of programs to carry out: after the transmitting the data in UART format in batches to the charging device via the GPIO ports, switching the device to be charged to be under a second charging mode, wherein a charging speech of the second charging mode is greater than that of the first charging mode.
 18. The device of claim 11, wherein the processor is an application processor of the device to be charged.
 19. The device of claim 11, wherein the processor is further configured to execute the plurality of programs to carry out: receiving data in UART format from the charging device via the GPIO ports after simulating the UART ports via the GPIO ports of the processor, wherein in receiving the data in UART format from the charging device via the GPIO ports of the processor, the processor is in a locked state, the processor is in an unlocked state during an interval between two adjacent batches of the data receiving.
 20. The device of claim 11, wherein the processor is further configured to process at least one interrupt during an interval between two adjacent batches of the data transmitting. 